Введение в процесс загрузки ZYNQ 7000

Обзор процесса загрузки системы

ZYNQ-7000 — это SoC на базе архитектуры ARM Cortex-A9 + FPGA. Его процесс загрузки управляется аппаратно (со стороны PS) и поэтапно выполняет запуск системы и конфигурацию программируемой логики. Процесс загрузки для SoC ZYNQ 7000 — это многоэтапная, гибко настраиваемая процедура, включающая сложные взаимодействия между автоматической аппаратной загрузкой и программным управлением. В этой статье будет представлен подробный анализ всего процесса, от включения питания до загрузки операционной системы.

Этап аппаратной инициализации

Включение питания и аппаратный сброс

• PS (ARM) и PL (FPGA) сбрасываются.

• Состояние выводов BOOT_MODE считывается для определения носителя загрузки.

• PL остаётся в несконфигурированном состоянии.

Инициализация источников питания и дерева тактирования

Последовательность POR (Power-On Reset)

• Все шины питания достигают стабильного состояния (сигнал PS_POR_B переходит в высокое состояние)

• Запускается внутренний генератор (типичная частота 33.33MHz)

• Делители частоты устанавливаются в значения по умолчанию

Конфигурация сети тактирования

​x
// Начальная конфигурация тактирования в BootROM
#define ARM_PLL_CTRL   0xF8000100
#define DDR_PLL_CTRL   0xF8000104
#define IO_PLL_CTRL    0xF8000108

// Типичные значения для инициализации
writel(ARM_PLL_CTRL, 0x0001A008);  // Установить PLL в режим обхода (bypass)

Определение режима загрузки

Режим загрузки определяется состоянием выводов MIO[5:2]:

Примечание: Состояние выводов режима считывается и фиксируется по нарастающему фронту сигнала POR_B

Этап BootROM (Stage-0)

BootROM

Код BootROM — это первое программное обеспечение, которое выполняется на устройстве Zynq после включения питания или сброса. Он начинает выполнение с адреса 0xFFFF_0000. BootROM недоступен для пользователя. Код BootROM хранится во встроенном ПЗУ (ROM), отсюда и название BootROM. Поскольку ZYNQ содержит 256КБ ОЗУ (RAM) и 128КБ ПЗУ (ROM), код BootROM может постоянно храниться в ПЗУ и не будет утерян при отключении питания. Обычно внутреннее ПЗУ чипа — это NOR Flash. Ключевой особенностью NOR Flash является eXecute In Place (XIP), что позволяет приложениям выполняться непосредственно из Flash-памяти без необходимости загрузки в системное ОЗУ. Это ПЗУ, встроенное в чип, и его нельзя изменить.

Код BootROM выполняет следующие функции:

• Инициализирует внутреннее оборудование PS.

• Считывает заголовок BOOT.BIN и FSBL с загрузочного носителя.

• Считывает состояние выводов режима загрузки для определения загрузочного устройства.

• Инициализирует тактовые генераторы и периферийные устройства.

• Считывает загрузочный образ с выбранного загрузочного устройства.

• Анализирует заголовок образа и проверяет его корректность.

• Загружает раздел FSBL в OCM.

• Передает управление FSBL.

Порядок выполнения кода BootROM в режиме загрузки с SD-карты:

1. Инициализирует выводы MIO, в основном настраивая регистры конфигурации физических характеристик для выводов MIO. Ключевым шагом является мультиплексирование MIO40~MIO45 для выполнения функций выводов CLK/CMD/DATA для периферийного устройства SD0.

2. Инициализирует периферийное устройство SD-карты и его драйвер, обеспечивая возможность операций чтения/записи на SD-карту.

3. Тестирует функциональность чтения/записи SD-карты.

4. Считывает файл BOOT.BIN из файловой системы SD-карты и анализирует заголовок BootROM. Файлу BOOT.BIN предшествует секция заголовка, организованная в определенном формате. Этот заголовок содержит такую информацию, как адрес загрузки FSBL, его размер и смещение внутри файла BOOT.BIN. Код BootROM способен анализировать этот заголовок.

5. Получив размер, смещение и адрес загрузки кода FSBL, код BootROM копирует код FSBL из файла BOOT.BIN в ОЗУ, а затем переходит по адресу выполнения FSBL для его запуска.

На этом этапе BootROM успешно запустил код FSBL.

Порядок загрузки в режиме QSPI

Последовательность выполнения кода BootROM в режиме загрузки с QSPI выглядит следующим образом:

1. Инициализация выводов MIO, мультиплексирование соответствующих выводов MIO для выполнения функций, необходимых периферии QSPI.

2. Инициализация периферии QSPI и её драйвера для устройства QSPI Flash, обеспечение возможности операций чтения/записи QSPI.

3. Тестирование функциональности чтения/записи QSPI.

4. Чтение файла BOOT.BIN с носителя QSPI и разбор заголовка Boot ROM.

5. После получения размера кода FSBL, смещения и адреса загрузки, код BootROM копирует код FSBL из файла BOOT.BIN в RAM и затем переходит по адресу выполнения FSBL для его запуска.

В отличие от метода поиска файловой системы, используемого для SD-карт, в режиме загрузки с QSPI код BootROM сначала ищет файл BOOT.BIN по адресу 0x000000 в QSPI. Если файл не найден, поиск продолжается по адресу 0x008000. Если и там файл не найден, переход осуществляется к следующему адресу 0x10000. Однако диапазон поиска не должен превышать первые 16 МБ адресного пространства QSPI.

Структура файла BOOT.BIN

BOOT.BIN — это основной файл образа загрузки для серии SoC ZYNQ 7000. (Образ загрузки — это упакованный файл, содержащий несколько программ или данных, необходимых для запуска системы, обычно двоичный файл, используемый для руководства системой через весь процесс от включения питания до запуска операционной системы. В Zynq образом загрузки обычно является файл BOOT.BIN. BOOT.BIN — это центральный файл для всей процедуры запуска системы и должен быть размещен в начале загрузочного устройства Zynq. Он считывается и выполняется кодом загрузки ROM Zynq из QSPI, SD-карты или NAND.) Он генерируется инструментом Bootgen на основе файла .bif и содержит все компоненты, необходимые для полной цепочки загрузки. Например:

xxxxxxxxxx
bif
the_ROM_image:
{
    [bootloader] fsbl.elf         // Partition 1: FSBL, must be first
    system.bit                    // Partition 2: FPGA configuration file (optional)
    u-boot.elf                    // Partition 3: Second-stage bootloader
}

В приведенном выше примере:

Общая структура файла

xxxxxxxxxx
┌───────────────────────┐
│       Boot Header     │ → Заголовок фиксированного формата (256 байт)
├───────────────────────┤
│  Partition Header Table│ → Описания разделов (20 байт/запись)
├───────────────────────┤
│     FSBL (Required)   │ → Первичный загрузчик
├───────────────────────┤
│   Bitstream (Optional)│ → Данные конфигурации PL
├───────────────────────┤
│ SSBL/App (Optional)   │ → U-Boot/ядро Linux, приложения и т.д.
├───────────────────────┤
│  Auth Cert (Optional) │ → RSA подпись/AES зашифрованные данные
└───────────────────────┘

Детали заголовка загрузки

Заголовок BOOT.BIN — это секция данных в начале файла BOOT.BIN, организованная в определенном формате, который может быть проанализирован кодом BootROM. BootROM считывает Заголовок Загрузки из образа загрузки, чтобы получить информацию об образе, такую как:

• Стартовый адрес FSBL.

• Источник ключа шифрования.

• Размер FSBL.

• Смещение FSBL.

• Контрольную сумму для проверки целостности заголовка.

Заголовок Загрузки должен существовать и быть правильно отформатирован. В противном случае BootROM не загрузит FSBL.

В файле BOOT.bin диапазон адресов от 0 до 0x8FF можно разделить на 17 частей, каждая из которых имеет определенное значение.

1. 0x000: Таблица векторов прерываний.

2. 0x020: Фиксированное значение 0xaa995566 (little-endian).

3. 0x024: Фиксированное значение 0x584c4e58 ASCII: XLNX.

4. 0x028: Если значение равно 0xa5c3c5a3 или 0x3a5c3c5a, образ зашифрован.

5. 0x02C: Номер версии заголовка BootROM, можно игнорировать.

6. 0x030: Этот параметр содержит количество байт от начала действительного заголовка BootROM до местоположения образа FSBL/пользовательского кода, которое является смещением адреса FSBL/пользовательского кода. Это смещение должно быть больше или равно 0x8C0.

7. 0x034: Записывает длину FSBL, используется для руководства кодом BootROM при копировании FSBL.

8. 0x038: Адрес загрузки, указывающий, куда копировать FSBL в OCM (обычно 0x0). Он направляет код BootROM, куда копировать FSBL в RAM.

9. 0x03C: Адрес выполнения FSBL в OCM (обычно определяется как 0x0). Он направляет код BootROM, по какому адресу RAM переходить для выполнения.

10. 0x040: Записывает длину FSBL.

11. 0x044: Фиксированное значение 0x01.

12. 0x048: Контрольная сумма (Вычисляется путем суммирования данных между 0x020 и 0x047 как 32-битных слов с последующим взятием побитового НЕ. Если сумма превышает 32 бита, для операции НЕ используются только младшие 32 бита).

13. 0x04C-0x097: Пользовательская область для FSBL/пользовательского кода. Можно заполнить нулями, если не нужна.

14. 0x098: Смещение до таблицы заголовков образов.

15. 0x09C: Расположение таблицы заголовков разделов.

16. 0x0A0-0x89F: Параметры для инициализации регистров.

17.0x8C0: FSBL и пользовательский код должны располагаться по этому адресу или после него.

Связанный код и анализ BOOT.BIN:

• Длину FSBL можно посмотреть по адресу 0x034:

  

• Адрес входа в таблицу векторов прерываний можно посмотреть по адресам 0x000-0x01F:

  

• Фиксированное значение можно посмотреть по адресу 0x020:

Выполнение кода BootROM

Начальный указатель PC

• ARM Cortex-A9 начинает выполнение с адреса 0x00000000

• Первые 64 КБ — это образ BootROM (только для чтения)

Этап FSBL (Stage-1)

Процесс инициализации

Последовательность конфигурации PS:

1. Инициализация контроллера DDR

2. Конфигурация мультиплексирования выводов MIO

3. Настройка системных тактовых частот

4. Включение контроллера прерываний

Основная роль FSBL

FSBL — это загрузчик первого этапа (First Stage Bootloader) в процессе загрузки Zynq, который напрямую загружается и выполняется BootROM. Его основные функции включают:

• Инициализация оборудования: Настройка базовой периферии, такой как память DDR, тактовые генераторы и MIO (Multi-use I/O).

• Разбор BOOT.BIN: Чтение таблицы заголовков разделов (Partition Header Table) из образа для идентификации различных разделов (например, Bitstream, SSBL, приложение).

• Загрузка последующих образов: Копирование программы второго этапа (например, U-Boot, bare-metal приложение, ядро Linux) по указанному адресу в памяти.

• Опциональная загрузка конфигурации PL: Если существует Bitstream для ПЛИС, FSBL загрузит его в секцию PL (программируемая логика).

Как FSBL загружает проект приложения?

Сценарий 1: Bare-metal приложение (Standalone)

• Структура BOOT.BIN:

  xxxxxxxxxx
  BOOT.BIN = FSBL + Bitstream (optional) + Application (.elf)
  

• Процесс:

  1. BootROM загружает FSBL во встроенную память (OCM, On-Chip Memory) и выполняет его.

  2. FSBL инициализирует DDR и загружает приложение (например, application.elf) из Flash/QSPI/SD-карты по указанному адресу в DDR (определенному в скрипте компоновщика, например, 0x00100000).

  3. FSBL переходит к точке входа приложения (обычно _start или main).

  Сценарий 2: Запуск Linux (через U-Boot)

• Структура BOOT.BIN:

  xxxxxxxxxx
  BOOT.BIN = FSBL + Bitstream (optional) + U-Boot
  

• Процесс:

  1. FSBL загружает U-Boot (SSBL) в DDR.

  2. U-Boot продолжает загрузку ядра Linux (uImage), дерева устройств (.dtb) и корневой файловой системы (например, rootfs.cpio) в память.

  3. U-Boot запускает ядро. На этом этапе FSBL завершил свою работу и больше не участвует в последующем процессе.

  Сценарий 3: Прямая загрузка Linux (без U-Boot)

• В редких случаях FSBL может напрямую загружать ядро Linux (которое должно быть сконфигурировано в формате kernel.img), но обычно рекомендуется использовать U-Boot в качестве посредника.

Взаимодействие между FSBL и приложением

• Без ОС: FSBL переходит непосредственно к приложению и не возвращается.

• С U-Boot: FSBL отвечает только за загрузку U-Boot, который затем управляет последующим процессом загрузки.

Конфигурация PL

Процесс загрузки Bitstream:

• Передается через интерфейс PCAP

• Ускоряется с помощью DMA (типичная пропускная способность 400 Мбит/с)

• Проверка статуса:

  xxxxxxxxxx
  #define PCAP_STATUS 0xF8007080
  #define PCAP_PROG_B 0xF80070F0
  
  void load_bitstream(uint32_t* addr, uint32_t size) {
      writel(PCAP_PROG_B, 0x0);  // Assert PROG_B
      delay(100);
      writel(PCAP_PROG_B, 0x1);  // De-assert PROG_B
      
      while(size > 0) {
          uint32_t data = *addr++;
          writel(PCAP_DATA, data);
          size -= 4;
          
          while(readl(PCAP_STATUS) & 0x4); // Wait for DMA to be ready
      }
  }
  

Оценка времени конфигурации:

Как найти U-Boot и Bitstream через BOOT.BIN

Файл BOOT.BIN содержит образ FSBL, образ u-boot и файл bitstream.

Код BootROM должен найти FSBL, разобрав информацию в заголовке BOOT.BIN. Затем код BootROM запускает FSBL.

После запуска кода FSBL он отвечает за поиск образа U-Boot и файла bitstream в файле BOOT.BIN, затем за загрузку файла bitstream в PL-часть ZYNQ и, наконец, за запуск U-Boot.

Это включает в себя три таблицы данных:

• таблица заголовков образов;

• таблица заголовков разделов;

• заголовок образа.

Таблица заголовков образов (Image Header Table)

Существует только одна таблица заголовков образов. Таблица заголовков разделов и заголовок образа идут парами. Количество образов, содержащихся в файле BOOT.BIN, определяет количество пар "таблица заголовков разделов - заголовок образа".

• 0x00: Номер версии таблицы заголовков образов;

• 0x04: Количество заголовков образов;

• 0x08: Смещение позиции первой таблицы заголовков разделов (Partition Header table). Рассчитывается в словах, поэтому фактическое смещение нужно умножить на 4;

• 0x0C: Смещение позиции первого заголовка образа (Image Header). Измеряется в словах;

• 0x10: Смещение аутентификации заголовка. Измеряется в словах;

• 0x1C: Дополняется значением 0xFFFFFFFF до тех пор, пока вся таблица заголовков образов не достигнет размера 64 байта.

Заголовок образа (Image Header)

• 0x0: Смещение адреса следующего заголовка образа. Если здесь 0, это означает, что это последний заголовок образа;

• 0x4: Смещение позиции связанной таблицы заголовков разделов;

• 0x8: Этот адрес всегда равен 0;

• 0xC: Значение фактического количества разделов;

• 0x10-N: Записывает имя образа.

• переменный: Используется для выравнивания.

Таблица заголовков разделов (Partition Header Table)

• 0x0: Длина данных зашифрованного раздела; единица измерения — слова, поэтому при вычислении необходимо умножить на 4;

• 0x4: Длина данных незашифрованного раздела. Если этот раздел — u-boot, это поле указывает длину u-boot, вычисляется так же;

• 0x8: Общая длина зашифрованных данных + выравнивание + расширение + данные аутентификации;

• 0xC: Адрес загрузки данных этого раздела, указывающий, куда в память следует скопировать данные;

• 0x10: Адрес выполнения данных этого раздела, указывающий адрес памяти для перехода при выполнении кода этого раздела;

• 0x14: Смещение позиции данных этого раздела внутри файла BOOT.BIN. Копирование начинается с этого адреса;

• 0x18: Биты атрибутов;

• 0x1C: Количество секций;

• 0x20: Позиция поля контрольной суммы;

• 0x24: Позиция заголовка образа, соответствующего этой таблице заголовков разделов. В единицах слов;

• 0x28: Поля, связанные с шифрованием;

• 0x2C-0x38: Не определено;

• 0x3C: Контрольная сумма.

Иерархические отношения и функции трех ключевых структур данных: Image Header Table, Partition Header Table и Image Header

Иерархическая структура

Подробное объяснение

Image Header

• Функция: Описывает глобальные атрибуты всего загрузочного образа.

• Типичные поля:

  xxxxxxxxxx
  typedef struct {
      uint32_t magic;          // Magic number (e.g., "XNLX")
      uint32_t version;        // Image version
      uint32_t partition_num;  // Number of partitions
      uint32_t header_checksum;// Header checksum
  } ImageHeader;
  

• Место хранения: Начало файла образа.

Image Header Table

• Функция: Индексирует метаданные всех разделов (а не сами данные разделов).

• Содержимое:

  • offset, size и load_addr каждого раздела

  • Указатель на сертификат аутентификации раздела

• Пример:

  xxxxxxxxxx
  typedef struct {
      uint32_t partition_offset;  // Offset of the partition data within the image
      uint32_t partition_size;
      uint32_t load_address;      // Address to load into memory
      uint32_t attribute_word;    // Partition attributes (encryption/authentication, etc.)
  } ImageHeaderTableEntry;
  

Partition Header Table

• Функция: Описывает подробные атрибуты одного раздела.

• Типичные поля:

  xxxxxxxxxx
  typedef struct {
      uint32_t exec_address;   // Execution entry address
      uint32_t auth_cert_offset; // Authentication certificate offset
      uint8_t  hash[32];       // Partition hash value
      uint8_t  reserved[16];
  } PartitionHeaderTable;
  

• Ключевые отличия:

  • Каждый раздел имеет свою собственную независимую таблицу заголовков раздела

  • Содержит информацию о безопасности, специфичную для раздела (например, хэш, сертификат)

Рабочий процесс

BootROM считывает Image Header для проверки целостности образа.

FSBL анализирует Image Header Table для нахождения всех разделов.

Для каждого раздела:

• Проверить легитимность раздела (RSA/хэш) через Partition Header Table.

• Загрузить его в память по адресу, указанному в Image Header Table.

Глубокий анализ исходного кода FSBL (First Stage Boot Loader)

Общая архитектура и процесс загрузки FSBL

FSBL — это первый программируемый пользователем код, выполняемый после включения питания платформы ZYNQ. Он в основном отвечает за инициализацию оборудования и загрузку загрузчика следующего этапа. Его основная архитектура выглядит следующим образом:

Анализ основных модулей кода

Инициализация оборудования (функция main())

xxxxxxxxxx
int main(void) {
    // 1. PS7 initialization (MIO/PLL/clocks/DDR)
    Status = ps7_init();
    
    // 2. Unlock SLCR registers
    SlcrUnlock();
    
    // 3. Cache handling
    Xil_DCacheFlush();
    Xil_DCacheDisable();
    
    // 4. Register exception handlers
    RegisterHandlers();
    
    // 5. Peripheral initialization (based on boot mode)
    switch(BootModeRegister) {
        case QSPI_MODE: InitQspi();
        case NAND_MODE: InitNand();
        case SD_MODE: InitSD();
        // ...
    }
    
    // 6. Load boot image
    HandoffAddress = LoadBootImage();
    
    // 7. Hand off control
    FsblHandoff(HandoffAddress);
}

Загрузка загрузочного образа (функция LoadBootImage())

xxxxxxxxxx
u32 LoadBootImage(void) {
    // 1. Get boot status and multi-boot register values
    RebootStatusRegister = Xil_In32(REBOOT_STATUS_REG);
    MultiBootReg = Xil_In32(XDCFG_MULTIBOOT_ADDR_OFFSET);
    
    // 2. Get image start address
    ImageStartAddress = ComputeImageStart();
    
    // 3. Get partition header info
    Status = GetPartitionHeaderInfo(ImageStartAddress);
    
    // 4. Partition processing loop
    while (PartitionNum < PartitionCount) {
        // - Validate partition header
        Status = ValidateHeader(HeaderPtr);
        
        // - Load partition data
        Status = PartitionMove(ImageStartAddress, HeaderPtr);
        
        // - Security verification (RSA/checksum)
        if (SignedPartitionFlag) {
            Status = AuthenticatePartition(...);
        }
        
        // - PL bitstream handling
        if (PLPartitionFlag) {
            Status = PcapLoadPartition(...);
        }
        
        PartitionNum++;
    }
    
    return ExecAddress; // Return handoff address
}

Ключевые структуры данных

Структура заголовка раздела (PartHeader)

xxxxxxxxxx
typedef struct {
    u32 image_word_len;    // Partition length in the image (in words)
    u32 data_word_len;     // Actual data length (in words)
    u32 partition_word_len;// Total partition length (in words)
    u32 load_addr;         // Load address (DDR)
    u32 exec_addr;         // Execution address
    u32 partition_offset;  // Partition offset in the image
    u32 attribute;         // Attribute word (encryption/signature, etc.)
    u32 checksum;          // Partition header checksum
} PartHeader;

Битовые маски слова атрибутов

xxxxxxxxxx
#define ATTRIBUTE_PL_IMAGE_MASK     0x20    // PL bitstream partition
#define ATTRIBUTE_PS_IMAGE_MASK     0x10    // PS code partition
#define ATTRIBUTE_RSA_PRESENT_MASK  0x8000  // RSA signature present
#define ATTRIBUTE_PARTITION_OWNER_MASK 0x30000 // Partition owner

Реализация механизма безопасности

Процесс безопасной загрузки

Ключевые функции безопасности

xxxxxxxxxx
// RSA signature verification
Status AuthenticatePartition(u8 *PartitionStart, u32 Length) {
    // 1. Verify signature
    if (XSecure_RsaVerify(...) != XST_SUCCESS) {
        return XST_FAILURE;
    }
    // 2. Check hash
    if (ValidateHash(...) != XST_SUCCESS) {
        return XST_FAILURE;
    }
    return XST_SUCCESS;
}

// Decrypt encrypted partition
Status DecryptPartition(u32 Addr, u32 DataLen, u32 ImgLen) {
    // Decrypt using AES engine
    XDcfg_AesDecrypt

Загрузка второго этапа

Загрузка U-Boot

Пример карты памяти:

xxxxxxxxxx
0x00000000 - 0x0003FFFF: BootROM + FSBL
0x00100000 - 0x001FFFFF: U-Boot
0x00200000 - 0x002FFFFF: Device Tree
0x03000000 - 0x04000000: Linux Kernel
0x08000000 - : Root File System

Переменные окружения U-Boot:

xxxxxxxxxx
setenv bootargs 'console=ttyPS0,115200 root=/dev/mmcblk0p2 rw earlyprintk'
setenv loadaddr 0x03000000
setenv fdtaddr 0x00200000
bootm ${loadaddr} - ${fdtaddr}

Реализация безопасной загрузки

Процесс аутентификации

Шаги верификации RSA:

Процесс расшифровки AES:

• Использование BBRAM или eFUSE для хранения ключа

• Режим CBC, 256-битный ключ

• Независимый IV для каждого раздела

Расширенные возможности

Мультизагрузка

Конфигурация регистров:

xxxxxxxxxx
#define MULTIBOOT_REG 0xF8000258
void set_multiboot(uint32_t offset) {
    uint32_t val = (offset >> 17) & 0x3FF;  // Convert to 128KB blocks
    writel(MULTIBOOT_REG, val | 0x1);      // Enable bit
}

Пример разметки Flash-памяти:

xxxxxxxxxx
0x000000: Golden Image (Backup)
0x100000: Primary Image v1.0
0x200000: Primary Image v2.0
0x300000: Diagnostic Image

Отладка и оптимизация

Устранение распространенных проблем

Диагностика сбоев загрузки:

Советы по оптимизации производительности:

• Включите передачу через QSPI DMA (установите QSPI_CR[3]=1)

• Запускайте FSBL в режиме XIP (Execute-In-Place)

• Сжимайте bitstream (через BITSTREAM.CONFIG.COMPRESS)

Приложение

Справочник по ключевым регистрам

Регистры SLCR:

xxxxxxxxxx
0xF8000000 - System-Level Control Registers
0xF8000B00 - MIO Pin Control
0xF8000D00 - Clock Control

Регистры DevCfg:

xxxxxxxxxx
0xF8007000 - PCAP Control
0xF8007030 - Security Configuration
0xF80070A0 - Multiboot Control

Ссылки на официальную документацию

• UG585: Техническое справочное руководство по Zynq-7000

• UG821: Руководство разработчика программного обеспечения для Zynq-7000

• UG873: Учебное пособие по встраиваемому дизайну

• XAPP1175: Безопасная загрузка СнК Zynq-7000